這個系列最後一篇。前 29 篇從終端機與 Shell 如何把命令交給程式，寫到 Command、Arg 與 Flag 的拆解、輸出與互動、程式架構、安全防護、REST API、WebSocket、OAuth 登入、串流對話、終端機編輯器與測試。主題雖然不同，面對的使用者只有兩種：在終端機前手動操作的人，以及在背景呼叫命令的腳本與 AI Agent。

即便有許多圖形介面與 Web 工具，CLI 仍是開發者每天使用的介面。AI Agent 也用它探索與操作系統，因為命令與結果都是文字，可以直接讀寫。這篇依序整理兩種使用者各自需要的設計：人類需要清晰的資訊層次與順暢的互動，程式與 AI 需要穩定、可解析的輸出與錯誤。

人類介面：資訊展現與互動體驗

CLI 不該是難用的文字介面。人類在終端機操作時，依賴清晰的資訊層次與即時回饋來降低認知負擔：

• 狀態與進度透明化：對於網路連線、批次處理或耗時任務，透過 Spinner、進度條（Progress Bar）與分階段提示，展現執行進度與當前狀態，消除等待時的黑盒子焦慮。
• 資訊層次與色彩語義化：善用顏色語義與字體排版，協助使用者從大量輸出中迅速聚焦重點，建立視覺上的階層感。
• 資料結構化與動態排版：處理清單或複合資料時，使用自動對齊的表格（Table View）、樹狀圖（Tree）或結構化摘要，取代未經處理的文字字串，提升閱讀效率。
• 互動引導與自動完成：提供 Shell 自動完成（Auto-completion）、選單與表單引導，降低死背子命令與 Flag 的記憶成本。
• 友善的排錯建議：操作失敗時，錯誤訊息應直接指出失敗原因與具體建議（例如提示缺少哪些參數或修正方向），避免僅印出底層系統代碼。

程式與 AI 依賴 UNIX 標準分工

UNIX 哲學定義的管道與通道分工，是程式與 AI Agent 能穩定串接 CLI 的基礎：

• stdout（標準輸出）：只存放命令成功產生的資料。不論是腳本 pipe 到下一階段，還是 AI 讀取結果，stdout 的內容都應該是純粹、可被解析的資料。
• stderr（標準錯誤）：存放所有非主要結果的資訊，包括排錯 Log、警告、進度提示與診斷訊息。這能確保 stdout 的資料流不被雜訊污染。
• Exit Code：0 代表執行成功，非 0 代表失敗。程式與 AI 自動化流程完全依賴 Exit Code 控制邏輯，絕不能在輸出錯誤訊息的同時回傳 0。

在 AI 時代把 CLI 打造為 Agent-friendly 工具

相較於 GUI 或頻繁變更的 API 憑證，以文字為基礎的 CLI 天然適合大型語言模型（LLM）呼叫。讓 CLI 成為 Agent-friendly 工具，需要滿足三個契約：

• 結構化輸出（--output=json）：提供欄位固定的 JSON 格式，讓 AI 無須用正則表達式解析純文字表格，降低 LLM 提取資料的錯誤率。
• 完全非互動模式（Non-interactive Flags）：AI 無法在執行中手動回應 Prompt。所有互動選單都必須有對應的 Flag（如 --yes、--config）或環境變數，讓 AI Agent 能夠一鍵完成執行。
• 可自我修正的錯誤診斷（Diagnostic for Self-healing）：當命令執行失敗時，stderr 的診斷文字必須包含具體的修正建議（例如缺少什麼參數、正確格式為何）。AI Agent 閱讀診斷訊息後，便能理解失敗原因並自動修正命令重新執行。

一個好的 CLI 介面，畫面可能只有幾行文字，但它建立了一套穩定連接人類、程式與 AI 的契約。搞懂這些邊界與設計原則，不論是自己用、給團隊用，還是交給 AI Agent 呼叫，寫出來的 CLI 都能持續發揮價值。

最後，希望這個系列能帶來一些實用的啟發。CLI 的開發門檻並不高，但延伸出的設計樂趣與應用場景卻非常豐富。不論是為了簡化日常的工作流程，還是打造給團隊或 AI 呼叫的自動化工具，動手寫一個屬於自己的 CLI 試試看吧！